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Abstract. Compositional verification and abstraction are the key tech- 
niques to address the state explosion problem associated with model 
checking of concurrent software. A promising compositional approach 
is to prove properties of a system by checking properties of its compo- 
nents in an assume-guarantee style. This article proposes a framework for 
performing abstraction and assume-guarantee reasoning of concurrent C 
code in an incremental and fully automated fashion. The framework uses 
predicate abstraction to extract and refine finite state models of software 
and it uses an automata learning algorithm to incrementally construct as- 
sumptions for the compositional verification of the abstract models. The 
framework can be instantiated with different assume-guarantee rules. We 
have implemented our approach in the ComFoRT reasoning framework 
and we show how ComFoRT out-performs several previous software 
model checking approaches when checking safety properties of non- trivial 
concurrent programs. 


1 Introduction 

The verification of concurrent software is acknowledged as an important and 
difficult problem. Model checking [12] is becoming a popular technique for soft- 
ware verification [3,4,18,24]. Given some formal description of a system and 
of a required property, model checking automatically determines whether the 
property is satisfied by the system. The limitation of the approach is the state 
space explosion problem, where the number of reachable states of a concurrent 
system increases exponentially with the number of its components. 

It is generally recognized that compositional reasoning and abstraction are 
the key techniques to combat state-space explosion. Together these two paradigms 
enable us to reduce the problem of verifying a large system into several smaller 
tasks of verifying simpler systems [28]. We present a framework that uses assume- 
guarantee style compositional reasoning and predicate abstraction for the auto- 
mated verification of concurrent software. Our work is done in the context of 
concurrent C programs with synchronous (blocking) message passing communi- 
cation, e.g. client server protocols, schedulers, telecommunication applications, 
NASA autonomy software, etc. We consider safety properties that describe the 
legal (and illegal) sequences of actions that a system is allowed to perform. 



Assume-guarantee reasoning checks properties of a system by proving prop- 
erties of its components under assumptions that these components make about 
their respective environments [27,30]. Intuitively, an assumption characterizes 
all contexts in which a component is expected to operate correctly. These as- 
sumptions also need to be discharged, by verifying that the rest of the system 
indeed satisfies them. This style of reasoning is often non-trivial, typically re- 
quiring human input to determine appropriate assumptions. Therefore, to apply 
assume-guarantee techniques on software of industrial complexity it is imperative 
that we construct appropriate assumptions in a completely automated manner. 

The proposed framework builds on our previous work which uses learning to 
automate assume-guarantee style verification [14]. That work was done in the 
context of checking two components expressed as finite state labeled transition 
systems. In contrast, this article presents an implementation and evaluation of 
automated assume-guarantee verification for infinite state systems (using ab- 
straction and refinement). Moreover, we address the verification of programs 
written in an advanced programming language (i.e. C), in the context of two or 
more components using symmetric and non-symmetric assume-guarantee rules. 

To check that a system made up of several software components satisfies a 
property, our framework follows the iterative counterexample guided abstraction 
refinement (CEGAR) paradigm [11]. In each iteration, we first use predicate 
abstraction [19] to build automatically finite state models which are conservative 
abstractions (with respect to safety properties) of the software components. We 
then use the L* learning algorithm [2,31] to build incrementally assumptions 
that are used for the compositional verification of the abstract models. 

If the outcome of the verification is that the property holds on the abstract 
model, we conclude that the property also holds on the original system. Oth- 
erwise, we analyze the returned counterexample to see if it corresponds to a 
real error or if it is a spurious behavior introduced by the abstraction process. 
In the latter case, we use the counterexample to refine automatically the ap- 
propriate abstract models and repeat the CEGAR loop. The process is carried 
out component wise, without it ever being necessary to build the state space of 
the whole system. Furthermore, our verification procedure is flexible and can be 
instantiated with different assume-guarantee rules. 

There has been substantial work on compositional reasoning [1,13,21,23] 
and abstraction [3, 15] for software verification. However, there are few instances 
where these two techniques have been combined effectively to enable auto- 
mated analysis of complex concurrent software. The MAGIC tool [7, 10] uses a 
two- level abstraction scheme for the compositional verification of concurrent, 
message-passing C programs. We show (in Section 6) how our framework out- 
performs MAGIC when checking several properties in a non-trivial concurrent 
C program (74,000 LOC). The BLAST tool [6] uses predicate abstraction and 
assume-guarantee reasoning for checking race conditions in multi-threaded C 
code. In contrast to our work, it targets shared memory communicating pro- 
grams, and therefore it uses a different style of assume guarantee rule. Moreover, 
the approach used by BLAST is not based on learning- 



We summarize our contributions (and the organization of this article) as 
follows. We describe a novel framework (Section 3) that uses assume-guarantee 
reasoning (Section 4), predicate abstraction and automated CEGAR (Section 5) 
for the compositional analysis of concurrent, message passing C programs. We 
present instantiations of the framework with several assume-guarantee rules. 
Other rules could be used, provided that they are sound in the context of our 
framework. We provide an implementation and case studies showing the merits 
of our approach (Section 6); we also evaluate the scalability of our approach 
with* increasing number of components by comparing our implementation with 
the state of the art model checker SPIN [32] . 

We end the paper with an overview of related work (Section 7) and conclu- 
sions (Section 8). In the next section we provide some background information. 

2 Background 

We use Labeled Transition Systems (LTSs) to model the behavior of communi- 
cating components in an (abstracted) concurrent system. As described in Sec- 
tion 4, we use proof rules that require the “complement” of an LTS. LTSs are not 
closed under complementation (their languages are prefix-closed), so we need to 
define here a more general class of finite state machines (FSMs). 

Let Act be the universal set of observable actions and let r denote a local 
action unobservable to a component’s environment. 

Definition 1 (FSM). An FSM M is a tuple (Q,aM,5,qQ,F) where: (i) Q is a 
non-empty finite set of states, (ii) aM C Act is a finite set of observable actions 
called the alphabet of M, (Hi) 5 C Q x (aM U {r}) x Q is a transition relation, 
(iv) qO € Q is the initial state , and (v) F C Q is a set of accepting states. 

An LTS is a special instance of an FSM for which all states are accepting. An 
FSM M — ( Q , aM,S,qO,F) is non- deterministic if it contains r-transitions or if 
3 (q, a, <?'), (q,a,q ,r ) € 5 such that q f ^ q" . Otherwise, M is deterministic. 


Traces A word (or trace) is an element of Act * . For an FSM M and a word £, 
we use S(q , t) to denote the set of states that M can reach after reading t starting 
at state q. A word t is said to be accepted by an FSM M = (Q,aM,S,qO, F) 
if S(qO,t) ftf / The language accepted by M, denoted C (M) is the set 
{t | 6(q0 , t) fl F 0}. For E C Act , we use t\E to denote the trace obtained by 
removing from t all occurrences of actions a £ E. We use [t, 17] to denote the 
FSM whose alphabet is E and whose language is the singleton set {t}. 

Definition 2 (Parallel Composition). Let M\ = (Qi,aMi,6i,q0i,Fi) and 
M 2 = (Q 2 , <xM 2 , S 2 , q0 2 <> F 2 ) be two FSMs. Then Mi || M 2 is an FSM M — 
(Q,aM,5,qQ,F), where : (i) Q = Q\ x Q 2 , (ii) aM = aMi U aM 2 , (Hi) F = 
Fi x F 2 , (iv) qO = (q0i,q0 2 ), and (v) ((si,s 2 ), a, (s£,4)) € S iff ((si, a, s£) € 
<5*1 A s 2 = $2 A a aM 2 ) V ( s 2 , a , S 2 ) € S 2 A Si =• A a ^ aMi) V ((si , a, s^) € 
Si A (52, a, s f 2 ) € S 2 A a ^ r). 



The parallel composition operator || is a commutative and associative operator 
that combines the behavior of two components by synchronizing the actions 
common to their alphabets and interleaving the remaining actions. 

Properties and Satisfiability A property is defined as an LTS P, whose 
language £ (P) defines the set of acceptable behaviors over oP. An FSM M 
satisfies P, denoted as M |= P, if and only if Vi € £ (M) . t\aP £ £ (P). 

Completion An FSM is complete with respect to some alphabet if every state 
has an outgoing transition for each action in the alphabet. Completion typically 
introduces a new non- accepting state and it adds transitions to the new state so 
that the automaton becomes completes. 

Complementation The complement of an FSM (or an LTS) M, denoted M, 
is an FSM that accepts the complement of M’s language. It is constructed by 
first making M deterministic, subsequently completing it with respect to aM, 
and finally turning all accepting states into non-accepting ones, and vice-versa. 

Weakest Environment Assumption We will use the notion of the weakest 
environment assumption [17]. For any FSM M and property P, let WA(M,P) 
denote the weakest environment under which M can achieve P. In other words, 
WA(M, P ) is an FSM such that, for any FSM A, M\\A (= P iff A f= WA(M , P). 

The L* Algorithm The learning algorithm (L*) used by our approach was 
developed by Angluin [2] and later improved by Rivest and Schapire [31]. L* 
learns an unknown regular language U over an alphabet E and produces a 
deterministic FSM C such that C(C) = U. L* works by incrementally producing 
a sequence of candidate deterministic FSMs C\ y C 2 , ... converging to C. In order 
to learn U, L* needs a Teacher to answer two types of questions. The first 
type is a membership query , consisting of a string a £ E*] the answer is true 
if cr £ U , and false otherwise. The second type of question is a conjecture , i.e. 
a candidate deterministic FSM Ci whose language the algorithm believes to be 
identical to U. The answer is true if C (Q) = U . Otherwise the Teacher returns 
a counterexample, i.e. a string cr in the symmetric difference of £ (Ci) and U. 

At a higher level, L* creates a table where it incrementally records whether 
strings in E * belong to U. It does this by making membership queries to the 
Teacher. At various stages L* decides to make a conjecture. It constructs a de- 
terministic FSM Ci based on the information contained in the table and asks the 
Teacher whether the conjecture C l is correct. If it is, the algorithm terminates. 
Otherwise, L* uses the counterexample returned by the Teacher to extend the 
table with strings that witness differences between £ (Ci) and U. 

L* is guaranteed to terminate with a minimal automaton C for the unknown 
language U . Moreover, each candidate FSM C t that L* constructs is smallest, 
in the sense that any other deterministic FSM consistent with the table from 
which Ci was constructed has at least as many states as Ci. The candidates 
conjectured by L* strictly increase in size; each candidate is smaller than the 
next one, and all incorrect candidates are smaller than C . Therefore, if C has n 
states, L* makes at most n — 1 incorrect conjectures. 
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Fig. 1 . Assume-guarantee verification of source code 

3 Framework for Compositional Verification of Software 

Our approach advocates a combination of learning based assume-guarantee style 
reasoning (described in Section 4) and predicate abstraction techniques (de- 
scribed in Section 5) to verify real-life programs. 

The approach is illustrated in Figure 1. Consider two message-passing C 
programs C x and C 2 , and let P be a safety property describing the legal sequences 
of actions in Ci||C 2 (generalization to more than two components is done as 
described in Section 4). We want to check C X \\C 2 (= P. The state space of each 
of the two C programs may be very large, or even infinite. Predicate abstraction is 
used to extract finite conservative models M x and M 2 of C x and C 2 respectively. 

Since the state space of M X \\M 2 could still be prohibitively large, we break up 
the verification of M X \\M 2 by using learning based assume-guarantee reasoning. 
The learning box, which can be instantiated with different assume-guarantee 
rules, computes in an iterative manner, appropriate assumptions that are neces- 
sary for the compositional verification of M X \\M 2 . Since M x and M 2 are finite, 
the process is guaranteed to terminate, stating either that the property holds 
for M x \\M 2 , or returning a counterexample if the property is violated. 

If M X \\M 2 (= P, we conclude that it is also the case that C X \\C 2 (= P, 
since M x and M 2 are conservative abstractions. Otherwise, the counterexample 
is analyzed to see if it corresponds to an error in C X \\C 2 , or if it is spurious as a 
result of the abstraction. In the latter case, the counterexample is exploited to 
automatically refine the set of predicates used by the predicate abstraction and 
the process is repeated. 

Our framework builds increasingly precise abstract models and assumptions. 
If time or memory is not sufficient to reach termination, intermediate results 
may still contain useful information and may be further analyzed. The generated 
assumptions may be useful in approximating the requirements that a component 
places on its environment to satisfy certain properties, while the abstract models 
approximate the behavior of the software components. 







4 Assume-guarantee Verification for Finite State Models 

In this section we discuss the use of different proof rules in the context of learning 
based assume-guarantee verification of finite state systems. 

4.1 Automated assume-guarantee verification for two components 

Rule 1 In our previous work on assumption generation and learning [14], we 
used the following basic assume-guarantee rule for establishing that a property 
P holds for the parallel composition of two finite state models of software com- 
ponents Mi and M 2 . 

1 : Mi || A Ml [= P 

2 : M 2 fy Am x 

Mi || M 2 \= P 

Am 1 denotes an assumption about the environment in which Mi is placed. The 
alphabet of Am x is (aMi U aP) H q?M 2 . 

The approach presented in [14] iterates a process based on gradually learning 
an assumption that is strong enough for Mi to satisfy P but weak enough to be 
an abstraction of M 2 ’s behavior. The learning process generates candidate as- 
sumptions based on queries to component Mi and on counterexamples obtained 
by model checking the two premises of the rule, alternately For finite state 
systems, this process is guaranteed to terminate stating that the property holds 
in Mi||M 2 or returning a counterexample that exhibits a property violation. 

Rule 2 Rule 1 is not symmetric in its use of the two components. Symmetric 
rules are interesting in the context of our framework, as their use is expected to 
lead to earlier termination of the iterative process and to smaller assumptions. 
Several such rules are presented in [5]. We have implemented the following rule 
from [5] (other rules could also be easily incorporated). 

1 : Mi || A Mx |= P 

2 : My A M2 h P 

3 : A Ml i| Am 2 (= P 

Mi || M 2 \=P 

We require aP C aMiUaM 2 and (*Am 1 = olAm* — {olMi rtaM 2 )UaP (denoted 
a A). Intuitively, premise 3 ensures that the possible common traces of Mi and 
M 2 , which are ruled out by the two assumptions, satisfy the property. 

Proposition 1. Rule 2 is sound? [5]. 

The use of Rule 2 in the context of automated learning based assume-guarantee 
verification is illustrated in Figure 2. L* is used to generate incrementally an as- 
sumption for each component such that premises 1 and 2 of Rule 2 hold. Specif- 
ically, L* is used to iteratively learn the traces of WA(M\,P), and RA(M 2 ,P) 


5 Rule 2 is also complete [5] . 




Fig. 2. Learning based assume-guarantee verification 


respectively. Conjectures are intermediate assumptions. As in [14], model check- 
ing is used to implement the Teacher needed by L*. 

At each iteration, L* is used to build approximate assumptions A l Mi and 
A 3 m ■ , based on querying the system and on the results of the previous iteration. 
Premise 1 is then checked to determine whether M\\\A % m P. If the result is 
false, then the returned counterexample is not in the language of W A(M 1 ,P). 
The counterexample is therefore used to refine A l Mi , through learning. Premise 2 
is checked similarly, to obtain an assumption A j M2 such that M 2 \\A j M2 |= P. 

When the first two premises hold, premise 3 is checked to discharge the 
assumptions. If premise 3 holds, then, according to the compositional rule, M\ || 
M 2 |= P. Otherwise, the obtained counterexample t is analyzed as follows. 

1. Use model checking to determine if Mi| j[£, a A) f= P. If true, then t e 
C(WA(Mi ) -P)), so assumption A % Mi needs to be refined (through learning) 
and the whole verification process is repeated with a new iteration. Other- 
wise, get a new counterexample t\ and go to step 2. 

2. Similarly, check M 2 \\[t,aA] (= P. If true, assumption A J M2 is refined and the 
whole verification process is repeated with a new iteration. Otherwise, get a 
new counterexample £2 and go to step 3. 

3. We report any trace from t £ C ([£ 1 , a A U odkfi][|[£2> ctA U as a coun- 

terexample to Mi\\M 2 (= P. 

Proposition 2. i is a counterexample for M 1 WM 2 P- 

4.2 Generalization to n components 

So far, we have discussed assume-guarantee reasoning in the context of two 
components. Assume now that a system consists of n components Mi || • * • || M n . 
We are interested in generalizing the two rules presented above to reason about 
n components. We have implemented the following approaches. 







Generalization for Rule 1 We break the system M x || • ■ • || M n into two 
parts Mi and M ^ = M 2 || *** || M n , and we use Rule 1 for checking (using 
learning based assume-guarantee reasoning) M\ || M \= P. Then, the second 
premise of Rule 1 involves checking: M 2 || || M n \= where Am 1 is a 

generated assumption for Mi. To discharge this obligation, our implementation 
invokes itself recursively, to avoid the state-space explosion that can arise due to 
the composition of M 2 || * * • || M n . Note that this enables us to verify Mi || ... [| 
M n |= P without ever computing the composition of two or more components. 
We should note that this generalization approach is mentioned briefly in [14] as a 
future research direction. We provide here an implementation and an evaluation 
of its scalability with increasing number of components(cf. Section 6). 


Generalization for Rule 2 We generalize Rule 2 as follows. 

l..n : Mi |1 A Mx h P 
n- hi: Au x II ••• [[ A H P 

Ml || ... II Mn H P 


This rule is incorporated in a straightforward way into the assume-guarantee 
framework; the idea is to use learning for each assumption that appears in 
premises l..n of the rule, and to use the last premise to discharge these assump- 
tions. The drawback of using this rule is that it needs to compute the product 
of the complements of all the n assumptions to discharge the final premise. One 
way around this problem is to weaken the final premise. However this could 
result in a loss of completeness. In other words, a reported counterexample for 
Mi 1 1 M 2 P might not correspond to a real counterexample. 

4.3 Discussion 

For finite state systems, the iterative learning process is guaranteed to terminate. 
This follows from the correctness of L*, which guarantees that if it keeps receiving 
counterexamples, it will eventually, produce WA(Mi, P) and WA(M 2 , P) respec- 
tively. Note that the process may terminate before the weakest assumptions are 
constructed. It terminates as soon as two assumptions have been constructed 
that are strong enough to discharge the first two premises but weak enough for 
the third premise to produce conclusive results, i.e. to prove the property or 
produce a counterexample. 

The L* algorithm guarantees that the generated assumptions are minimal; 
they strictly increase in size, and grow no larger than the weakest assumptions 
WA(Mi,P) and WA(M 2 , P). We should note that, in the worst case, the cost of 
building directly the weakest assumption for a component is exponential in the 
size of that component [17]. However, for well designed software, the interfaces 
between components are usually small. Therefore, assumptions are expected to 
be much smaller than the components that they restrict in the compositional 
rules. It is in cases like this that we expect our learning based approach to work 
best. L* approximates the assumptions starting from very small state machines 


and it runs in time that is polynomial in the size of the automaton it is learn- 
ing [31]. Therefore, the cost of learning based assume-guarantee verification is 
expected to be small, as compared to non-compositional model checking or other 
compositional abstraction techniques (see also the results from Section 6). 

4.4 Extensions 

Our framework is flexible and it can be extended with other assume-guarantee 
rules. One candidate rule appears in [29]. The rule is circular and it uses in- 
duction over time to break the mutual dependence between components. Its 
incorporation in our framework is straightforward (similar to Rule 2). 

We are well aware that there is no single rule that can be effective in ad- 
dressing the state space explosion problem in all cases. Therefore, we plan to 
equip our framework with a library of different assume-guarantee rules and to 
evaluate their effectiveness on extensive case studies. The framework can use 
rules that are sound in the context of FSMs with blocking communication. Note 
that completeness of the rules is not required, although it is desirable. The use 
of incomplete rules guarantees positive results, but it might yield false coun- 
terexamples that can not be used in abstraction-refinement the positive results. 
To accommodate incomplete rules, further counterexample analysis is needed to 
determine if the returned counterexample indicates a real error. 

Another promising direction is the dynamic use of previously generated as- 
sumptions to verify evolving software in the presence of component up-dates or 
substitutions (see [9]). 

5 Abstraction and Refinement for C 

Given a (concurrent) C program made up of a number of components C\...C n , a 
set of predicates on program variables, and a safety property P, we use predicate 
abstraction to automatically build finite state LTSs respectively. These 

abstract models are conservative , i.e. C(C{) C £(M*) for i = We then 

check Mi||...||M n f= P. The results obtained from this verification are used to 
refine the abstract models, if necessary. The abstraction, counterexample valida- 
tion, and model refinement steps are all performed component-wise. We present 
an overview of abstraction and refinement here (for a detailed description see [8]). 
We improve upon [8], by using learning based assume- guarantee reasoning for 
checking Mi\\...\\M n f= P (cf. Section 3). 


Model construction Finite state LTSs are computed from the control flow 
graph of a program in combination with predicate abstraction. Given a set of 
predicates defined over the state variables of a program, predicate abstraction 
computes an abstract model that describes the behaviors of the original pro- 
gram in terms of these predicates. To decide properties such as equivalence of 
predicates, we use theorem provers. Once a finite set of predicates is chosen, the 
states of the corresponding abstraction are simply valuations of the predicates. 
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CFG Expanded CFG 

Fig. 3. Predicate abstraction for source code 


The transition relation of the abstract system is defined existentially, i.e., 
we postulate a transition from abstract state A to abstract state B if there 
are concrete states a and 6, associated with A and B respectively, that have 
a transition from a to b. Figure 3 provides a simple example illustrating these 
ideas. The left-hand side shows the control flow graph (CFG) of a simple C 
program with two integer variables x and t. Suppose now that we define a single 
predicate P := t = 0. Then corresponding to each control location we have two 
abstract states: P can either be True or False . The right-hand side shows the 
model that we obtain via predicate abstraction. Transitions are labeled with 
actions that can represent synchronization messages (absent here) , the return 
values of procedure calls, and internal actions. 

The initial set of predicates can be obtained in many ways, the most common 
being to collect formulas appearing in conditional expressions as well as in the 
property to be checked. The user is also able to specify predicates of interest, 
perhaps based on some deeper understanding of the system. New predicates are 
generated, if needed, in the model refinement phase, described next. 


Model refinement The model constructed by predicate abstraction is guaran- 
teed to be a conservative abstraction of the original system, meaning that each 
behavior in the original system is represented by some behavior in the model, al- 
though the model may contain more behaviors. As a result, if the model satisfies 
a safety property, then so does the original system [12]. However, a counterex- 
ample obtained by verifying the model may be spurious. The counterexample is 
analyzed, and, if it is spurious, it is used to derive additional predicates and con- 
struct a new, finer abstraction of the system. The verification is then repeated 
anew with the refined model. This abstract- verify-analyze counterexample-refine 
loop (CEGAR) continues until a real counterexample is obtained or the system is 
verified to be correct. In theory, the CEGAR loop is not guaranteed to terminate. 
In practice however, it has proved to be quite effective. 
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Fig. 4. Comparison between A-G based and two-level schemes. Time is in seconds, 
memory in MB. A * indicates timeout after 1 hr. Best figures are highlighted. 


6 Experimental Results 

We implemented our algorithms in the ComFoRT reasoning framework [26]. 
ComFoRT includes, among others, a model checking engine based on the magic 
tool [7], and hence inherits all the capabilities of MAGIC. In particular ComFoRT 
can extract finite LTS models from C programs using predicate abstraction 
and perform counterexample validation and abstraction refinement automati- 
cally and modularly as described in Section 5. 

In this section, we describe the evaluation of our techniques in the context 
of two sets of experiments. All our experiments were carried out on an AMD 
1800+ XP machine with 3 GB of RAM. 

Comparison with MAGIC In the first set of experiments we compared our 
approach with the one-level and two-level abstraction refinement schemes [10] 
which were already implemented in MAGIC. Given a concurrent system C\ ||...||C n 
and a safety property P, the one-level abstraction scheme uses predicate abstrac- 
tion and refinement to compute (component- wise) corresponding abstract mod- 
els M 1 ...M n and it checks (non-compositionally) if Mi||...||M n satisfies P. The 
two-level abstraction scheme combines predicate abstraction (used to compute 
abstract models M 1 ...M n ) with a second abstraction operating on events, which 
lumps together the states of the abstract models, if they perform the same set of 
actions, and refines these partitions according to reachable successor states. This 
second abstraction is also applied component- wise and it yields successive models 
that converge to the bisimulation quotient of the original abstract models. 

As the source code for our benchmarks we used OpenSSL version 0.9.6c 
which has about 74,000 LOC. We checked various safety properties of the initial 
handshake protocol between an SSL server and an SSL client. 

Figure 4 summarizes our results. We imposed a time limit of 1 hour and a 
memory limit of 2.5 GB. As expected the one- level approach shows the worst 
performance since it leverages the least amount of compositionality. More im- 
portantly, we see that the assume-guarantee (A-G) based approaches are also 
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Fig. 5. State machine showing the behavior of each philosopher 

consistently better than the two-level approach in terms of both time and mem- 
ory consumption. In some instances, the A-G based schemes are able to terminate 
successfully while the two-level approach times out. 

Between the two A-G based schemes, the use of Rule 1 enables faster veri- 
fication but consumes more memory. Intuitively this is because Rule 1 involves 
composing the concrete system M 2 with the generated assumption (cf. Section 4) 
while Rule 2 only requires the composition of the (negation of the) two assump- 
tions which are much smaller. 


Comparison with SPIN The second set of experiments were aimed at gaug- 
ing the scalability of our approach with increasing number of components and 
comparing our implementation with the SPIN [32] model checker. To this end we 
designed a benchmark based on the classical dining philosophers problem. Each 
instance of our problem consisted of n philosophers, n forks and a single lock. 

The behavior of each philosopher is shown in Figure 5. Intuitively, each 
philosopher behaves as follows. It first attempts to acquire the lock. On suc- 
cess it attempts to grab its left fork. On further success it non-deterministically 
chooses to either (case 1) go for its right fork or (case 2) release the lock and 
the left fork and go back to its initial state. In case 1, if it succeeds in getting 
the right fork, it releases the lock, eats, releases the right fork, then the left fork 
and goes back to its initial state. 

The safety property we attempted to verify states that it should never be 
the case that all n philosophers simultaneously go for case 1 (i.e., to state 5 
in Figure 5) since this would lead to an immediate deadlock. Clearly this is 
impossible since the lock ensures mutual exclusion. We encoded this system for 
increasing values of n using both C and Promela (the input language of spin). We 
then verified the safety property using ComFoRT and SPIN. We again imposed 
a time limit of 1 hour and a memory limit of 2.5 GB. 

For spin we used the compile time options -DSAFETY and -DMA=444 which 
lead to reduced memory consumption. Without these options, the performance 
of spin is even worse. For ComFoRT we report results for the non-symmetric 
Rule 1, generalized as described in Section 4. The use of Rule 2 scales poorly with 
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Fig. 6. Comparison between A-G based scheme and spin. Time is in seconds, memory 
in MB. A * indicates timeout after 1 hr. Best -figures are highlighted. 

increasing number of philosophers. This is because the third premise involves the 
composition of (the negations of) all the environment assumptions. 

The results are summarized in Figure 6. We observe that our A-G based 
approach is able to verify the system for up to 12 philosophers while spin times 
out after 9 philosophers. Furthermore the growth in time and space requirement 
is much better in our approach when compared to SPIN. The columns T-Inc and 
M-Inc show the ratio of time and memory between n and n — 1 philosophers. 
This ratio increases monotonically for SPIN while it seems to be stabilizing (or 
increasing but at a much slower rate) for the A-G approach. This suggests that 
while increase in resource usage for verification cannot be entirely avoided with 
increasing number of components in the system, it can be expected to be more 
tractable if we use assume-guarantee reasoning. 

7 Related Work 

Throughout the paper we have already discussed related work on abstraction 
and assume-guarantee style verification. Here we discuss software model checking 
approaches that are most closely to ours. 

SLAM [3] is a well-engineered tool that uses predicate abstraction, CEGAR 
and symbolic reachability analysis for verifying sequential C code. BLAST [6] has 
also focused primarily on CEGAR for sequential C code, using on-the-fly reach- 
ability for verification. Recently, BLAST has been extended to perform thread- 
modular abstraction refinement, in which assumptions and guarantees are both 
refined in an iterative fashion. The framework applies to concurrent programs 
that communicate through shared variables. The work in [16] also focuses on 
a shared-memory communicating programs but does not address notions of ab- 
stractions as is done in [22]. 

BANDERA [4] and JavaPathfinder (jpf) [33] are both aimed at verifying con- 
current Java programs. BANDERA employs data abstraction and modular rea- 




soning with user-supplied assumptions, but not automated assumption gener- 
ation and CEGAR, while jpf is an explicit state model checker for the non- 
compositional analysis of Java code, verisoft [18] and feaver [24] perform 
verification on concurrent C code; feaver supports data abstraction, but no 
modular reasoning, while VERISOFT uses partial order reduction techniques for 
efficient state-less verification. 

Learning in the context of software model checking has also been investigated 
in [20] and [25], but with a different goal. In those works, the L* Algorithm is 
used to generate models of software systems which can then be analyzed with 
model checking and testing techniques. 

8 Conclusions 

We presented a novel framework for performing abstraction and assume-guarantee 
reasoning for concurrent C code in an incremental and fully automated fashion. 
We discussed instantiations of the framework with symmetric and non-symmetric 
rules for the verification of systems with two or more components. We presented 
an implementation and case studies showing the merits of our approach. We 
evaluated the scalability of our approach with increasing number of components 
by comparing it to the state of the art model checker SPIN. 

To evaluate how useful our approach is in practice, we are planning its ex- 
tensive application to other (real-life) systems. However, our early experiments 
provide strong evidence in favor of this line of research. In the future, we plan 
to incorporate and evaluate other assume guarantee rules in our framework. We 
also plan to extend the types of properties that can be handled in our framework 
to include liveness and time related properties. 
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Appendix 

We provide here the proofs for the propositions that appear in the article. 
Lemma 1. For trace t and alphabets E, E f : E C E f => (t\E')\E = t\E. 



Lemma 2. The following is true about the language of Mi || M 2 : 

C {Mi || M 2 ) = {t£ {aMi U a M 2 )* | t\aM 1 G C (M x ) A t\aM 2 G C (M 2 )} 

Lemma 3. Let t,t be traces , E be an alphabet , and M an FSM such that i G 
T (M||[£, Z]). Then for any alphabet Z' C E, t\E' = t\E. 

Proof. Follows from Proposition 2 and the fact that the alphabet of [t, E] is E. 

We are now ready to give the proofs. Here is the proof for Proposition 1, 
which states that Rule 2 is sound. 

Proof By contradiction: assume that the three premises hold but the conclusion 
of the rule does not hold. Consider a trace t G £ (Mi ||M 2 ) that violates P, i.e. 
t\aP £ C (P). Let i = t\aA . Since aP C aA , it follows from Lemma 1 that 
t\aP = t\aP, hence t\aP £ L (P). 

Moreover, {t\{aM\ U aA))\aP is also the same as t\aP (and not in C (P)), 
since aP C (aMiUaA) (from Lemma 1). From Lemma 2, t\Mi G C (Mi). Hence, 
by premise 1 and since {t\{aMi U aA))\aP £ L (P), it follows that i £ C (A^), 
i.e. t G C (A Mx)- Similarly, by premise 2, t G C (Am 2 )- Since the alphabet of 
A Mi 1 1 ^ M 2 is also aA , it follows that t G C (Am 1 \\Am 2 )- Since t\aP £(P), 
then Ami\\Am 2 P, which contradicts premise 3. 

Here is the proof for Proposition 2, which asserts the correctness of the 
counterexample analysis. 

Proof From Lemma 3, tfaMi — ti\aM\ G C (Mi). Similarly, t\aM 2 G C (M 2 ). 
Therefore, from Lemma 2, t 6 £(Mi||M 2 ). From Lemma 3, t\aP = £1 (aP. 
Hence t\aP £ L (P). 



